좋아요. 아래는 **개발/검증/운영 VM 서버 스펙을 산정하기 위한 “근거 문서(new)”**입니다. 수치는 근거 기반의 보수적 기준 + 여유치를 적용해 바로 적용/수정할 수 있도록 정리했어요. (요청하신 Docker·OS 오버헤드, 스토리지 구분, HA 전제, 참고 URL 포함)

VM 서버 스펙 산정 근거 (new)

0) 전제 및 목표

• 워크로드 가정

  • 개발: 사용자 20, 동시접속 10(≈50%)

  • 검증: 운영의 60~70% 부하를 단일 노드로 재현(부하/성능 테스트 실행을 위한 여유 포함)

  • 운영: 사용자 200, 동시접속 100(≈50%), HA 2노드 액티브-액티브

• 구성요소: Mendix 애플리케이션(Runtime은 자바 기반), Java/Tomcat 또는 JBoss, Docker/Compose로 컨테이너링, RHEL 8 기반 VM

• SLO 예시: P95 응답시간 < 300ms, 오류율 < 1% (조직 표준에 맞춰 조정)

1) 자원 산정 원칙

1.1 CPU

• 컨테이너 오버헤드는 최신 리눅스/컨테이너 환경에서 **거의 미미(0~2%대)**로 보고됨. 실측 벤치·연구에서도 네이티브 대비 유의미한 차이가 거의 없음 → 여유치로 +5% 반영. HathoraMDPIwp BRENDEN com

• Kubernetes/컨테이너 기준으로 요청/상한을 명시(예: Mendix 소형 템플릿 0.1 vCPU/512Mi부터 시작)하고 실측으로 조정. MendixKubernetes

1.2 메모리(RAM)

• 자바 애플리케이션은 JVM Heap + 메타스페이스/스레드스택 등 비-Heap + 네이티브/파일캐시까지 고려해야 함. Heap만으로는 부족하므로 총 RAM을 Heap의 1.5~2.0배로 계획. OpenLogiceG Innovations

• JBoss/Tomcat 계열 권장 관행: JVM Heap을 시스템 RAM의 최대 절반 이내에서 시작(예: 32GB RAM → Xmx ≤ 16GB) 후 부하테스트로 조정. Red Hat DocumentationTaashee.com

• OS 예약분: 파일캐시/버퍼 포함 **15~20%**는 운영체제에 상시 남김(메모리 압박 시 스왑/성능저하 방지 목적). Red Hat DocumentationUnix & Linux Stack Exchange

• 컨테이너 오버헤드는 작지만 안전 여유로 +5% 포함. MDPI

1.3 디스크(스토리지)

• 기본스토리지(OS, Docker 엔진/이미지/레이어, 런타임/시스템 로그) +
  추가스토리지(애플리케이션 로그, 미디어/첨부파일, 백업/아카이브)를 분리 산정.

• RHEL 8 최소 요건: RAM ≥ 1.5~4GB(아키텍처별), 디스크 ≥ 10GiB 이상. 실무는 패키지/업데이트/코어덤프 고려해 OS 파티션 40~60GB 이상 권장. Red Hat Documentation

• Docker는 기본적으로 자원 제한이 없으므로 이미지/레이어 증가와 로그 회전 정책에 주의. 런타임 모니터링은 docker stats로 상시 확인. Docker Documentation+2Docker Documentation+2

1.4 오버헤드 합산

• VM OS 1520% + 컨테이너 5% ≈ 총 2025% 가산(보수적).
  (귀사 표준이 **OS 1015% + Docker 510%**이면 중앙값 20%로 동일하게 운용 가능) MDPI

2) 산정 로직(요약 공식)

1. 동시접속자 기준 애플리케이션 필요치 추정

• 시작점(보수):

  • CPU: 1 vCPU 당 경량 트랜잭션 30~50 CCU 가정 → 100 CCU ≈ 2~4 vCPU로 시작 후 APM로 조정

  • Heap: 50 CCU 당 2~4GB 시작 → 100 CCU ≈ 4~8GB Heap 시범 → GC/스레드 덤프·APM으로 조정
    (이 구간은 애플리케이션 복잡도/쿼리/미디어 처리에 크게 좌우되므로 부하테스트 필수. Mendix 공식 템플릿/컨테이너 리소스 요청을 초기값으로 두고 상승) MendixOpenLogic

2. 총 RAM = (JVM Heap × 1.5~2.0) + 캐시 여유

• 그리고 OS 15~20% + 컨테이너 5% 여유 추가. Red Hat Documentation+1MDPI

3. 디스크

• OS 4060GB + Docker(이미지/레이어) 2040GB + 시스템/컨테이너 로그 여유 20~40GB

• 애플리케이션 로그: (예상 로그/일 × 보존일수) × 1.3(압축/피크)

• 미디어/첨부: (일평균 증가량 × 보존기간) × 1.2(메타/썸네일)

• 필요 시 데이터/미디어는 별도 볼륨으로 분리(성능/백업/보안 이점). Docker

3) 환경별 초기 스펙(제안치)

아래 수치는 “초기 배치값(Starting Size)”입니다. APM 계측(메모리/GC/스레드/DB), docker stats, 로드테스트로 2~4주 내 리사이징을 권장합니다. Docker Documentation

3.1 개발(20명, 동시 10)

• 구성: 단일 노드, 모든 컴포넌트 경량화(Hot reload/빌드 툴 고려)

• CPU: 4 vCPU (병렬 빌드/로컬 테스트 여유 포함)

• RAM: 16 GB (JVM Heap 4~6GB 시작, 상한 8GB까지 시도)

• 디스크(총 200 GB 권장)

  • 기본스토리지: OS 50GB + Docker 30GB + 시스템/컨테이너 로그 40GB

  • 추가스토리지: 앱로그 40GB(개발 보존 7~14일), 미디어 40GB

• 오버헤드 여유(20%) 내 포함

• 근거: RHEL 요구사항, JVM/컨테이너 관행, Docker 모니터링 가능성. Red Hat DocumentationOpenLogicDocker Documentation

3.2 검증(운영의 60~70% 부하 단일 노드 재현)

• 구성: 단일 노드(성능/부하/장애 복구 시나리오 테스트 전용)

• CPU: 8 vCPU

• RAM: 32 GB (Heap 8~12GB로 시작, 상한 16GB 이내)

• 디스크(총 300~400 GB 권장)

  • 기본스토리지: OS 60GB + Docker 40GB + 시스템/컨테이너 로그 60GB

  • 추가스토리지: 앱로그 80120GB(보존 1430일), 미디어 80~120GB

• 근거: 운영의 피크 시나리오 1노드에 집중하는 worst-case 검증, JVM Heap≤RAM/2 권고. Red Hat Documentation

3.3 운영(200명, 동시 100, HA 2노드)

• 구성: 2노드 액티브-액티브, 노드당 50~60 CCU 목표(노드 장애 시 단일 노드가 100 CCU 흡수)

• 노드당 CPU: 8 vCPU

• 노드당 RAM: 32 GB (Heap 8~12GB 시작, 상한 16GB 이내)

• 노드당 디스크(총 400 GB 권장)

  • 기본스토리지: OS 60GB + Docker 60GB + 시스템/컨테이너 로그 80GB

  • 추가스토리지: 앱로그 100GB(보존 30~90일 정책에 맞춰 조정), 미디어 100GB 이상(업무 특성 따라 증설/분리 권장)

• 합산 가산치(오버헤드): 약 20% 포함( OS 15% + Docker 5% 가정)

• 근거: 컨테이너 오버헤드가 낮으나 운영 안정성 위해 여유치 부여, 장애 시 단일 노드 수용 설계. Hathora

참고: Mendix 배포 템플릿은 매우 작은 리소스에서 시작하므로(예: 0.1 vCPU/512Mi) 초기 기동은 작게 → 지표 기반으로 상향이 이상적입니다. 운영은 반대로, 안정 여유를 두고 시작 → 관측 후 하향이 안전합니다. Mendix

4) 스토리지 산정(예시 수식)

• 앱 로그: 일평균 2GB × 보존 30일 × 1.3(피크/압축) ≈ 78GB → 100GB 할당

• 미디어: 일평균 1GB × 180일 × 1.2 ≈ 216GB → 별도 볼륨 250GB 시작

• 시스템/컨테이너 로그: 0.5GB/일 × 30일 × 1.3 ≈ 20GB → 40~80GB

• OS + Docker: OS 60GB + Docker 이미지/레이어 40~60GB(멀티스테이지/정기정리 전제)

• 정책: 로그 로테이션/보존(예: size 100M, rotate 30), 이미지 정리(docker system prune) 표준화. Docker

5) 모니터링 및 튜닝 절차

1. 부하/성능 테스트로 CPU 한계, GC 정지시간, 스레드풀, DB 대기 파악

2. docker stats/APM으로 컨테이너별 CPU/RAM/IO를 지속 계측, 리미트/리퀘스트 재조정 Docker Documentation+1

3. JVM 튜닝: Xms/Xmx, GC(예: G1), 스레드스택, 메타스페이스 경계 적용, Heap ≤ RAM/2 원칙 준수 Red Hat DocumentationeG Innovations

4. OS 레벨: 메모리 압박/스왑 회피 설정 점검, 커널 파라미터 검토(테스트 후 sysctl 반영) Red Hat Documentation

6) 참고 URL (근거 자료)

• Mendix 컨테이너 리소스 예시(쿠버네티스 템플릿) 및 시스템 요구사항: MendixMendix Documentation

• Docker 자원 제한/모니터링 문서(docker stats, 리소스 설정): Docker Documentation+2Docker Documentation+2

• 컨테이너 성능 오버헤드(연구/벤치): HathoraMDPI

• RHEL 8 최소 사양/용량: Red Hat DocumentationRed Hat Customer Portal

• JVM/Tomcat/JBoss 메모리·튜닝 가이드: OpenLogicRed Hat DocumentationeG Innovations

빠른 적용 메모

• 초기 배치: Dev 4vCPU/16GB/200GB, QA 8vCPU/32GB/300~400GB, Prod(HA) 노드당 8vCPU/32GB/400GB

• Heap 시작점: Dev 46GB, QA 812GB, Prod 8~12GB (상한 RAM/2 이내)

• 오버헤드 가산: 총 20%(OS 15% + 컨테이너 5%)를 용량/성능에 반영

• 필수 작업: 로테이션/보존 정책 적용, 2~4주 관측 후 리사이징

원하시면 이 내용을 PPT 또는 PDF 템플릿으로 바로 내보내 드릴게요. (조직 표준 머리말/꼬리말, 표/그래프 포함 버전으로도 가능합니다.)

좋습니다 👍 요청하신 내용을 표와 문서 형태로 정리했습니다. 아래는 “VM 서버 스펙 산정 근거” 문서입니다.

VM 서버 스펙 산정 근거

1. 산정 기준

• 개발환경: 사용자 20명, 동시접속자 약 10명 (50%)

• 검증환경: 운영환경 부하(60~70%)를 단일 노드로 검증

• 운영환경: 사용자 200명, 동시접속자 약 100명 (50%), HA 구성(2대)

• 구성요소: Mendix Java (Spring, JBoss, Tomcat 등, Docker 컨테이너)

• 스토리지:

  • 기본스토리지(OS, Docker, 로그용)

  • 추가스토리지(애플리케이션 로그, 미디어 파일)

• 오버헤드 고려:

  • Docker + Docker Compose: VM 자원 대비 약 5~10%

  • VM OS: VM 자원 대비 약 10~15%

2. 환경별 VM 스펙 제안 (표)

※ 디스크는 OS, Docker 이미지/레이어, 로그, 애플리케이션 로그, 미디어 파일을 합산하여 산정.
※ 오버헤드(약 20% 합산: OS 1015% + Docker 510%)를 포함한 값.

3. 스토리지 산정 근거

• 기본스토리지:

  • OS 설치 및 패키지 업데이트: 40~60GB

  • Docker 이미지/레이어: 30~60GB

  • 시스템/컨테이너 로그: 40~80GB

• 추가스토리지:

  • 애플리케이션 로그: (일평균 로그량 × 보존일수) × 1.3

  • 미디어 파일: (일평균 증가량 × 보존기간) × 1.2

4. 오버헤드 고려

• VM OS 오버헤드: 10~15%

• Docker + Compose 오버헤드: 5~10%

• 총 가산치: 약 20%

5. 참고 URL (근거 자료)

• Red Hat Enterprise Linux 8 System Requirements

• Docker 공식 문서 – Resource constraints

• Docker stats를 통한 모니터링

• Mendix Kubernetes Deployment YAML 예시

• Tomcat/JVM 메모리 설정 가이드

• 컨테이너 오버헤드 성능 연구 (ACM/Usenix 논문 등)

📌 이 자료는 표준 스펙 산정 근거 문서이며, 실제 운영 시에는 APM 모니터링 / 부하 테스트 결과에 따라 CPU·메모리·스토리지를 조정하는 것이 필요합니다.

원하시면 제가 이 내용을 PDF 또는 PPT 발표자료 형태로 만들어드릴 수도 있습니다. 어느 쪽을 원하시나요?

알겠습니다. 요청하신 조건(개발/검증/운영, Mendix App on Docker, HA 2대, N+1 고려, 오버헤드 반영)을 기반으로 문서 + 표 형태의 산정 근거를 작성했습니다.

VM 서버 스펙 산정 근거

1. 산정 기준

• 개발환경: 사용자 20명, 동시접속자 10명(50%)

• 검증환경: 운영환경 부하(약 60~70%)를 단일 노드에서 검증

• 운영환경: 사용자 200명, 동시접속자 100명(50%), HA 2대(N+1)

  • 1노드 장애 시 단일 노드가 전체 부하(100 CCU)를 수용 가능해야 함

• 구성요소: Mendix 애플리케이션 (Docker 컨테이너 기반)

• 스토리지:

  • 기본스토리지: OS, Docker 엔진/이미지, 시스템 로그

  • 추가스토리지: 애플리케이션 로그, 미디어/첨부 파일

• 오버헤드 가산치:

  • Docker + Docker Compose: VM 자원의 5~10%

  • VM OS: VM 자원의 10~15%

  • 합산: 약 20%

2. 환경별 VM 스펙 제안

※ 운영환경은 N+1 원칙에 따라 단일 노드가 전체 동시접속 100명을 수용할 수 있도록 스펙 산정

3. 스토리지 산정 근거

• 기본스토리지

  • OS 설치 및 업데이트: 40~60 GB

  • Docker 이미지/레이어: 30~60 GB

  • 시스템/컨테이너 로그: 40~80 GB

• 추가스토리지

  • 애플리케이션 로그: (일평균 로그량 × 보존일수) × 1.3

  • 미디어 파일: (일평균 증가량 × 보존기간) × 1.2

4. 오버헤드 반영

• VM OS: 10~15%

• Docker + Compose: 5~10%

• 총 가산치: 약 20%

• 예: 실제 요구 16GB → VM 배포 시 20GB 이상 할당

5. 참고 URL (근거 자료)

• Red Hat Enterprise Linux 8 System Requirements

• Docker 공식 문서 – Resource constraints

• Docker stats – 컨테이너 모니터링

• Mendix Cloud Resource Guidelines

• Tomcat/JVM 메모리 튜닝 가이드

• 컨테이너 성능 오버헤드 연구 (USENIX ATC)

📌 정리하면:

• Dev: 4vCPU / 16GB / 200GB

• QA: 8vCPU / 32GB / 300~400GB

• Prod (HA, N+1): 노드당 8vCPU / 32GB / 400GB

• 오버헤드 20% 포함, 1노드 장애 시에도 전체 부하 수용 가능

원하시면 제가 이 내용을 PDF 보고서 혹은 PPT 발표자료 형태로 만들어 드릴 수 있습니다. 어떤 형식으로 원하시나요?

좋습니다. 요청 주신 내용을 기준으로 문서 형태 + 표로 정리해 드렸습니다.

VM 서버 스펙 산정 근거

1. 산정 기준

• 개발환경: 사용자 20명, 동시접속자 약 10명(50%)

• 검증환경: 운영환경 부하(60~70%)를 단일 노드에서 검증

• 운영환경: 사용자 200명, 동시접속자 약 100명(50%)

  • HA 2대 구성

  • N+1 구성: 1노드 장애 시 단일 노드가 전체 부하 처리 목표

• 구성요소: Mendix 애플리케이션 (Docker 컨테이너 기반)

• 스토리지 산정

  • 기본스토리지(OS, Docker, 로그용)

  • 추가스토리지(애플리케이션 로그, 미디어 파일)

• 오버헤드 고려

  • Docker + Docker Compose: VM 자원 대비 약 5~10%

  • VM OS: VM 자원 대비 약 10~15%

  • 합산 약 20% 가산

2. 환경별 VM 서버 스펙 (표)

3. 스토리지 산정 근거

• 기본스토리지

  • OS 설치 및 업데이트: 40~60 GB

  • Docker 이미지 및 레이어: 30~60 GB

  • 시스템/컨테이너 로그: 40~80 GB

• 추가스토리지

  • 애플리케이션 로그: (일평균 로그량 × 보존일수) × 1.3 (피크치 반영)

  • 미디어 파일: (일평균 증가량 × 보존기간) × 1.2 (메타데이터 포함)

4. 오버헤드 고려

• VM OS: 10~15%

• Docker + Compose: 5~10%

• 총 가산치: 약 20%

• 예시: 메모리 요구량이 16GB일 경우, 오버헤드를 포함해 약 20GB로 산정

5. 참고 URL (근거 자료)

• Red Hat Enterprise Linux 8 System Requirements

• Docker 공식 문서 – Resource constraints

• Docker stats – 컨테이너 모니터링

• Mendix Cloud Resource Guidelines

• Tomcat/JVM 메모리 튜닝 가이드

• 컨테이너 성능 오버헤드 연구 (USENIX ATC 2020)

📌 최종 요약:

• 개발: 4 vCPU / 16 GB / 200 GB

• 검증: 8 vCPU / 32 GB / 300~400 GB

• 운영(HA, N+1): 노드당 8 vCPU / 32 GB / 400 GB

• 오버헤드 20% 반영, 단일 노드 장애 시 전체 부하 처리 가능

👉 이 결과를 PDF 보고서와 PPT 발표자료 두 가지 형태로 변환할 수도 있습니다. 원하시는 출력 포맷은 PDF, PPT 중 어느 쪽일까요?

좋습니다. 요청하신 내용을 반영해 CPU, Memory, Disk 별 산정 근거를 문서와 표로 정리했습니다.

VM 서버 스펙 산정 근거

1. 산정 기준

• 개발환경: 사용자 20명, 동시접속자 약 10명 (50%)

• 검증환경: 운영환경 부하의 약 60~70%를 단일 노드에서 검증

• 운영환경: 사용자 200명, 동시접속자 약 100명 (50%), HA 2대

  • N+1 구성: 1노드 장애 시 단일 노드가 전체 부하(100 CCU) 처리 목표

• 구성요소: Mendix App (Docker 컨테이너 기반)

• 스토리지 산정

  • 기본스토리지: OS, Docker 엔진/이미지, 시스템 로그

  • 추가스토리지: 애플리케이션 로그, 미디어/첨부 파일

• 오버헤드

  • Docker + Docker Compose: VM 자원의 5~10%

  • VM OS: VM 자원의 10~15%

  • 합산 약 20%

2. 산정 근거 (CPU, Memory, Disk)

2.1 CPU

• 기준:

  • 경량 트랜잭션 처리 시 vCPU 1개 ≈ 동시접속자 30~50명 처리 가능

  • Mendix 앱(자바 기반)의 경우 100 CCU 처리에 약 2~4 vCPU 필요

  • 장애 시 단일 노드가 100 CCU 수용 가능해야 하므로 운영 노드당 8 vCPU 배치

• 근거 URL

  • Mendix Cloud Resource Guidelines

  • Docker Resource Constraints

2.2 Memory

• 기준:

  • JVM Heap + Non-Heap + OS Cache 고려 → Heap × 1.5~2.0배 필요

  • 운영 시 Heap 8~12GB, 시스템 RAM은 최소 32GB 할당

  • Docker 및 OS 오버헤드(총 20%) 포함하여 산정

• 근거 URL

  • Tomcat JVM Memory Tuning Guide

  • Red Hat Enterprise Linux 8 System Requirements

2.3 Disk

• 기본스토리지

  • OS 설치 및 업데이트: 40~60 GB

  • Docker 이미지/레이어: 30~60 GB

  • 시스템/컨테이너 로그: 40~80 GB

• 추가스토리지

  • 애플리케이션 로그: (일평균 로그량 × 보존일수) × 1.3

  • 미디어 파일: (일평균 증가량 × 보존기간) × 1.2

• 근거 URL

  • Docker Monitoring (docker stats)

  • USENIX ATC 2020 – Container Overhead Study

3. 환경별 VM 서버 스펙 (표)

4. 요약

• CPU: 운영환경은 장애 시 단일 노드가 100 CCU를 처리할 수 있도록 노드당 8 vCPU 할당

• Memory: JVM Heap 8~12GB 기준, 시스템 메모리는 32GB(오버헤드 20% 반영)

• Disk: OS/컨테이너/로그를 포함해 기본 200GB 이상, 추가 로그 및 미디어 파일 별도 할당

• 오버헤드: VM OS + Docker 합산 약 20% 여유치 반영

👉 원하시면 이 내용을 PDF 보고서나 PPT 발표자료로 변환해 드릴 수 있습니다.
어느 형식으로 제작해 드릴까요?

좋습니다. 요청하신 내용을 문서 형태 + 표로 정리했습니다. CPU, Memory, Disk로 각각 산정 근거를 기술하고, 운영환경의 N+1 조건과 오버헤드를 반영했습니다.

VM 서버 스펙 산정 근거

1. 산정 기준

• 개발환경: 사용자 20명, 동시접속자 약 10명 (50%)

• 검증환경: 운영환경 부하의 60~70%를 단일 노드에서 검증

• 운영환경: 사용자 200명, 동시접속자 약 100명 (50%)

  • HA 2대 구성

  • N+1: 1노드 장애 시 단일 노드가 전체 부하(100 CCU)를 처리 가능해야 함

• 구성요소: Mendix App (Docker 컨테이너 기반)

• 스토리지

  • 기본스토리지: OS, Docker 엔진/이미지, 시스템 로그

  • 추가스토리지: 애플리케이션 로그, 미디어/첨부 파일 등

• 오버헤드

  • Docker + Docker Compose: VM 자원의 5~10%

  • VM OS: VM 자원의 10~15%

  • 합산 약 20% 가산

2. 산정 근거

2.1 CPU

• vCPU 1개는 경량 트랜잭션 기준 동시접속자 30~50명 처리 가능.

• Mendix 자바 앱은 CPU 부하가 JVM 및 컨테이너 오케스트레이션에 따라 발생 → 100 CCU 처리에 최소 4~6 vCPU 필요.

• 운영환경은 N+1 원칙을 적용해 노드당 8 vCPU 할당.

• 참조:

  • Mendix Cloud Resource Guidelines

  • Docker Resource Constraints

2.2 Memory

• JVM Heap 메모리만 고려 시 부족 → Heap × 1.5~2배로 시스템 메모리 산정.

• 운영환경 기준 Heap 8~12GB 필요, 따라서 시스템 메모리 32GB 이상 권장.

• OS 예약 및 Docker 오버헤드(20%)를 합산.

• 참조:

  • Tomcat JVM Memory Tuning Guide

  • RHEL 8 System Requirements

2.3 Disk

• 기본스토리지

  • OS 설치 및 업데이트: 40~60GB

  • Docker 이미지/레이어: 30~60GB

  • 시스템/컨테이너 로그: 40~80GB

• 추가스토리지

  • 애플리케이션 로그: (일평균 로그량 × 보존일수) × 1.3 (피크치 포함)

  • 미디어 파일: (일평균 증가량 × 보존기간) × 1.2 (메타데이터 포함)

• 운영환경은 데이터 특성에 따라 총 400GB 이상 권장.

• 참조:

  • Docker Monitoring (docker stats)

  • USENIX ATC 2020 – Container Overhead Study

3. 환경별 VM 서버 스펙 (표)

4. 요약

• CPU: 운영환경은 장애 시 단일 노드에서 전체 100 CCU 처리 가능하도록 노드당 8 vCPU 할당.

• Memory: JVM Heap + 오버헤드 고려하여 노드당 32GB 권장.

• Disk: OS, Docker, 로그 포함 최소 200GB 이상. 운영환경은 로그/미디어 포함 노드당 400GB 권장.

• 오버헤드: VM OS(1015%) + Docker(510%) ≈ 20% 여유 반영.

📌 이렇게 작성된 내용을 PDF 보고서나 PPT 발표자료로 변환도 가능합니다.
👉 혹시 이 자료를 PDF 형식으로 원하시나요, 아니면 PPT 발표자료로 원하시나요?

알겠습니다. 요청하신 VM 서버 스펙 산정 근거 문서를 CPU / Memory / Disk 별로 정리하고, 표와 참조 URL까지 포함해 문서 형태로 작성했습니다.

VM 서버 스펙 산정 근거

1. 산정 기준

• 개발환경: 사용자 20명, 동시접속자 약 10명 (50%)

• 검증환경: 운영환경 부하의 60~70%를 단일 노드에서 검증

• 운영환경: 사용자 200명, 동시접속자 약 100명 (50%)

  • HA 구성(2대)

  • N+1 원칙 적용: 1노드 장애 시 단일 노드가 전체 부하(100 CCU)를 처리 가능해야 함

• 구성요소: Mendix App (Docker 컨테이너 기반)

• 스토리지 산정

  • 기본스토리지: OS, Docker, 로그

  • 추가스토리지: 애플리케이션 로그, 미디어 파일

• 오버헤드 고려

  • Docker + Docker Compose: VM 자원의 5~10%

  • VM OS: VM 자원의 10~15%

  • 합산 약 20% 가산

2. 산정 근거 (CPU / Memory / Disk)

2.1 CPU

• vCPU 1개 ≈ 30~50 동시 접속 처리 가능 (경량 트랜잭션 기준).

• Mendix App (Java 기반, 컨테이너 환경)에서 100 CCU 처리 시 4~6 vCPU 필요.

• 운영환경은 N+1 보장을 위해 노드당 8 vCPU 권장.

• 참조 URL

  • Mendix Cloud Resource Guidelines

  • Docker Resource Constraints

2.2 Memory

• JVM Heap + Non-Heap + OS Cache 고려 필요.

• JVM Heap 크기의 약 1.5~2배 RAM 필요.

• 운영환경 Heap 약 8~12GB 기준, 시스템 RAM은 32GB 권장.

• Docker(510%) + OS(1015%) 오버헤드 포함.

• 참조 URL

  • Tomcat JVM Memory Tuning Guide

  • RHEL 8 System Requirements

2.3 Disk

• 기본스토리지

  • OS 설치/업데이트: 40~60GB

  • Docker 이미지 및 레이어: 30~60GB

  • 시스템/컨테이너 로그: 40~80GB

• 추가스토리지

  • 애플리케이션 로그: (일평균 로그량 × 보존일수) × 1.3

  • 미디어 파일: (일평균 증가량 × 보존기간) × 1.2

• 운영환경은 총 400GB 이상 권장.

• 참조 URL

  • Docker Monitoring – docker stats

  • USENIX ATC 2020 – Container Overhead Study

3. 환경별 VM 서버 스펙 (표)

4. 요약

• CPU: 운영환경은 단일 노드가 100 CCU를 수용할 수 있도록 노드당 8 vCPU 산정.

• Memory: JVM Heap + 오버헤드 고려, 노드당 32GB 권장.

• Disk: OS 및 Docker 포함 최소 200GB 이상, 운영환경은 로그·미디어 포함 400GB 권장.

• 오버헤드: VM OS(1015%) + Docker(510%) ≈ 20% 여유 반영.

👉 이 자료를 PDF 보고서 또는 PPT 발표자료로 변환해드릴 수도 있습니다. 원하시는 출력 형식은 PDF일까요, PPT일까요?

좋습니다. 요청하신 내용을 기준으로 개발/검증/운영 환경별 CPU, Memory, Disk 산정 근거를 정리했습니다. 표와 문서 형식으로 작성했고, 참조한 사이트 URL도 포함했습니다.

VM 서버 스펙 산정 근거

1. 산정 기준

• 개발환경: 사용자 20명, 동시접속자 약 10명(50%)

• 검증환경: 운영환경 부하의 약 60~70%를 단일 노드에서 검증

• 운영환경: 사용자 200명, 동시접속자 약 100명(50%), HA 2대 구성

  • N+1 원칙 적용: 1노드 장애 시 단일 노드가 전체 부하(100 CCU)를 처리 가능해야 함

• 구성요소: Mendix App (Docker 컨테이너 기반)

• 스토리지

  • 기본스토리지: OS, Docker, 시스템 로그

  • 추가스토리지: 애플리케이션 로그, 미디어 파일

• 오버헤드

  • Docker + Compose: VM 자원의 5~10%

  • VM OS: VM 자원의 10~15%

  • 합산 약 20%

2. 산정 근거

CPU

• 개발환경: 빌드 및 테스트 위주, 동시접속 10명 수준 → 4 vCPU 권장

• 검증환경: 운영 대비 60~70% 부하 시뮬레이션 → 8 vCPU 권장

• 운영환경: 100 CCU 처리 + N+1 고려 → 노드당 8 vCPU 권장

• 참조

  • Mendix Cloud Resource Guidelines

  • Docker Resource Constraints

Memory

• JVM Heap 메모리 외에 Non-Heap, OS Cache 고려 필요.

• Heap의 약 1.5~2배 RAM 산정, 오버헤드(20%) 추가.

• 개발환경: Heap 4GB 기준 → 16GB RAM 권장

• 검증환경: Heap 8GB 이상 필요 → 32GB RAM 권장

• 운영환경: Heap 8~12GB 필요 → 32GB RAM 권장

• 참조

  • Tomcat JVM Memory Tuning Guide

  • RHEL 8 System Requirements

Disk

• 기본스토리지

  • OS: 40~60GB

  • Docker 이미지/레이어: 30~60GB

  • 시스템 로그: 40~80GB

• 추가스토리지

  • 애플리케이션 로그: (일평균 로그량 × 보존일수) × 1.3

  • 미디어 파일: (일평균 증가량 × 보존기간) × 1.2

• 개발환경: 총 200GB (기본 120GB + 추가 80GB)

• 검증환경: 총 300400GB (기본 160GB + 추가 140240GB)

• 운영환경: 노드당 400GB (기본 200GB + 추가 200GB)

• 참조

  • Docker Monitoring – docker stats

  • USENIX ATC 2020 – Container Overhead Study

3. 환경별 VM 서버 스펙 (표)

4. 요약

• CPU: 운영환경은 단일 노드 장애 시 전체 100 CCU 처리 가능하도록 노드당 8 vCPU 산정.

• Memory: JVM Heap과 OS/Docker 오버헤드 고려, 노드당 32GB 권장.

• Disk: 개발 200GB, 검증 300~400GB, 운영 400GB(노드당).

• 오버헤드: VM OS(1015%) + Docker(510%) ≈ 20% 여유치 반영.

👉 이 자료를 바로 PDF 또는 PPT로 내보내 드릴 수도 있습니다. 원하시는 출력 형식이 있을까요?

좋습니다. 요청하신 조건을 반영해 개발/검증/운영 환경별 CPU·Memory·Disk 산정 근거를 문서 + 표 형태로 정리했습니다. 운영환경은 **N+1(1노드 장애 시 단일 노드로 전체 부하 흡수)**을 목표로 잡았고, OS 1015% + Docker 510% ≈ 총 20% 오버헤드를 반영했습니다. 핵심 근거는 Docker·Kubernetes·Mendix·RHEL 공식 문서를 우선 인용했습니다.

VM 서버 스펙 산정 근거

1) 산정 기준(요약)

• 개발: 사용자 20명, 동시접속 10명

• 검증: 운영 부하의 60~70%를 단일 노드에서 검증

• 운영(HA 2대): 사용자 200명, 동시접속 100명 / N+1 → 1노드 장애 시 단일 노드가 100 CCU 처리

• 구성요소: Mendix App (Docker 컨테이너)

• 스토리지 항목: 기본스토리지(OS, Docker, 로그) / 추가스토리지(앱 로그, 미디어 파일)

• 오버헤드: VM OS 1015% + Docker 510% ≈ 총 20% 여유 반영. Docker는 컨테이너별 CPU/메모리 리밋 설정과 실시간 docker stats 모니터링을 지원(운영 중 계측·튜닝 전제). Docker Documentation+1

2) 산정 로직(방법론)

A. CPU 산정

• 요청/상한 기반으로 컨테이너 CPU를 설정하고(쿠버네티스 기준 millicore 개념: 1 vCPU=1000m), 초기값은 보수적으로 잡은 뒤 지표 기반 상·하향 조정. KubernetesMendix

• 운영(N+1): 노드 한 대가 100 CCU를 처리하도록 노드당 8 vCPU로 시작(장애 시에도 성능 여유 확보 목적). 실측으로 조정.

• 근거 포인트: CPU 요청/제한은 플랫폼(쿠버네티스/도커)이 직접 강제·스케줄링하며, 요청·제한의 단위를 명시하면 예측가능성이 올라감. Docker DocumentationKubernetes

B. Memory 산정

• JVM 기반 앱은 Heap 외에 Metaspace/Thread stack/Native 메모리 + OS 페이지캐시가 필요 → RAM ≈ Heap × 1.5~2.0을 출발점으로 권장. Tomcat/JVM은 -Xms/-Xmx로 최소/최대 Heap을 명시 설정. Mendix DocumentationOracle Docs

• 운영 초기값: Heap 8~12GB, 시스템 RAM 32GB로 시작(오버헤드 20% 포함). 이후 GC·메모리 그래프를 기준으로 조정. Mendix Documentation

C. Disk 산정

• 기본스토리지(OS, Docker 엔진/이미지/레이어, 시스템/컨테이너 로그):

  • RHEL 8 최소 디스크 10GiB이나, 패키지·업데이트·코어덤프·도커 레이어를 고려해 OS 40~60GB 이상 권장. Red Hat Documentation

  • Docker는 이미지/레이어/빌드캐시로 용량 증가 → docker system df로 점검, docker system prune/image prune으로 정리 정책 운영. Docker Documentation+3Docker Documentation+3Docker Documentation+3

• 추가스토리지(앱 로그·미디어):

  • 앱 로그 = (일평균 로그량 × 보존일수) × 1.3(피크·압축여지)

  • 미디어 = (일평균 증가량 × 보존기간) × 1.2(메타데이터/썸네일)

  • Mendix Docker 빌드팩의 파일 저장 경로(PV 마운트 필요) 참고 ⇒ 파일 업로드는 /opt/mendix/build/data/files에 영구 저장 권장. Medium

3) 환경별 스펙(표)

숫자는 초기 배치값(Starting size) 입니다. 부하/성능 테스트 + docker stats/APM 지표로 2~4주 내 리사이징을 권장합니다. Docker Documentation

• 오버헤드: 상기 스펙은 OS 1015% + Docker 510% ≈ 총 20% 여유를 내재화하여 산정. Docker는 컨테이너별 메모리 하드/소프트 리밋 설정 가능(메모리 고갈 리스크를 낮춤). Docker Documentation

• 요청/제한 자동 관리: (쿠버네티스 사용 시) CPU/메모리 requests/limits로 예측 가능한 스케줄링·격리 확보. Kubernetes

4) CPU·Memory·Disk 상세 산정근거

4.1 개발환경

• CPU: 로컬 빌드/테스트 부하, IDE/도커 병행 → 4 vCPU로 시작. (컨테이너별 CPU 제한은 필요 시 0.5~1 vCPU 단위로 설정) Docker Documentation

• Memory: JVM Heap ~4–6GB 가정 → 시스템 16GB(Heap×1.5~2 + OS/Docker 20% 포함). -Xms/-Xmx로 상·하한 명시. Oracle Docs

• Disk: OS 50 + Docker 30 + 시스템로그 40 + 여유(이미지 캐시/빌드캐시) + 앱로그/미디어 80. 필요 시 docker system df/prune 주기화. Docker Documentation+1

4.2 검증환경

• CPU: 운영의 60~70% 부하를 단일 노드에 집중 → 8 vCPU로 시작. 부하테스트로 병목(스레드풀/DB wait) 확인 후 조정.

• Memory: Heap 8~12GB 가정 → 시스템 32GB(OS/Docker 오버헤드 포함). Mendix Java 메모리 분해/그래프 지표로 튜닝. Mendix Documentation

• Disk: 테스트 로그 보존 1430일 가정 → 300~400GB. (OS 60, Docker 40, 시스템로그 60 + 앱로그/미디어 140240). docker stats로 I/O 및 메모리 스파이크 동시 관찰. Docker Documentation

4.3 운영환경(HA 2대, N+1)

• CPU: 노드당 8 vCPU. 장애 시 단일 노드 100 CCU 수용. CPU 요청·제한을 명시해 스로틀링/노이즈 네이버 효과를 제어. Docker DocumentationKubernetes

• Memory: 초기 Heap 8~12GB, 시스템 32GB. 메모리 사용률·GC 정지시간을 관찰하며 단계 조정. (Mendix 모니터링/알람으로 컨테이너 메모리 퍼센트 확인) Mendix Documentation+1

• Disk: 노드당 400GB. 앱 업로드 파일은 PV로 분리해 /opt/mendix/build/data/files 경로 마운트 권장(팟 재기동 시 데이터 보존). 로그는 보존일 × 일평균 산식으로 산정. Medium

5) 운영 수칙(요약)

• 모니터링: docker stats(CPU/메모리/네트워크/블록 I/O), 플랫폼 대시보드(Grafana/HPA 지표) 활용. Docker DocumentationMendix

• 리미트 관리: 컨테이너별 메모리 하드/소프트 리밋, CPU 제한 설정. Docker Documentation+1

• 디스크 청소: 정기 docker system df/prune 정책 운영, 이미지·볼륨·빌드캐시 관리. (주의: 볼륨 삭제 전 백업!) Docker Documentation+2Docker Documentation+2

• OS 용량: RHEL8 최소 10GiB이나 실무는 OS 40~60GB 이상 확보. Red Hat Documentation

6) 참고 URL(근거 자료)

• Docker 공식: Resource constraints(메모리/CPU 리밋) — https://docs.docker.com/engine/containers/resource_constraints/ Docker Documentation

• Docker 공식: docker stats 런타임 지표 — https://docs.docker.com/reference/cli/docker/container/stats/ Docker Documentation

• Docker 공식: docker system df / prune — https://docs.docker.com/reference/cli/docker/system/df/ · https://docs.docker.com/engine/manage-resources/pruning/ · https://docs.docker.com/reference/cli/docker/system/prune/ Docker Documentation+2Docker Documentation+2

• Kubernetes 공식: 컨테이너 리소스 요청/제한 — https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/ Kubernetes

• Mendix 공식: Docker 배포 가이드 — https://docs.mendix.com/developerportal/deploy/docker-deploy/ Mendix Documentation

• Mendix 공식: Private Cloud(Kubernetes) 가이드 & 릴리즈 노트 — https://docs.mendix.com/developerportal/deploy/private-cloud/ · https://docs.mendix.com/releasenotes/developer-portal/mendix-for-private-cloud/ Mendix Documentation+1

• Mendix 공식: Java Memory Usage(메모리 세그먼트 설명) — https://docs.mendix.com/refguide/java-memory-usage/ Mendix Documentation

• Tomcat/자바: JVM 힙 설정(Xms/Xmx) — https://tomcat.apache.org/tomcat-9.0-doc/config/ Oracle Docs

• RHEL 8: 시스템 요구사항(최소 디스크/메모리) — https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/automatically_installing_rhel/system-requirements-and-supported-architectures_rhel-installer Red Hat Documentation

• (참고) Mendix 블로그: 쿠버네티스 CPU 단위/오토스케일 개념 — https://www.mendix.com/blog/scaling-your-private-cloud-infrastructure-strategies-for-handling-growth/ Mendix

빠른 적용 메모

• 초기 배치: Dev 4vCPU/16GB/200GB, QA 8vCPU/32GB/300~400GB, Prod(HA) 노드당 8vCPU/32GB/400GB

• 메모리: Heap 8~12GB에서 시작(+오버헤드 20%), GC/지표로 조정

• 디스크: OS 4060GB + Docker 3060GB + 시스템로그 40~80GB + (앱로그/미디어 산식)

• 운영 목표: N+1 보장(단일 노드 100 CCU 수용)

필요하시면 이 문서를 PPT 또는 PDF로 바로 내보내 드릴게요.

좋습니다. 아래에 개발/검증/운영 환경별로 CPU·Memory·Disk 산출 근거를 상세 기술하고, 표로도 정리했습니다. 운영환경은 N+1(1노드 장애 시 단일 노드가 전체 부하 처리) 목표, OS 1015% + Docker 510% ≈ 총 20% 오버헤드를 반영했습니다. 마지막에 참조 URL을 함께 넣었습니다.

VM 서버 스펙 산정 근거 (Mendix App on Docker)

1) 산정 기준(요약)

• 개발: 사용자 20명 / 동시접속 10명(≈50%)

• 검증: 운영 부하의 60~70%를 단일 노드에서 재현(성능/장애/복구 테스트 포함)

• 운영(HA 2대, N+1): 사용자 200명 / 동시접속 100명(≈50%), 1노드 장애 시 단일 노드가 100 CCU 전량 처리

• 구성요소: Mendix 애플리케이션(자바 기반), Docker/Compose

• 스토리지 항목:

  • 기본스토리지: OS, Docker 엔진/이미지/레이어, 시스템/컨테이너 로그

  • 추가스토리지: 애플리케이션 로그, 미디어(첨부) 파일

• 오버헤드: VM OS 10~15% + Docker/Compose 5~10% → 총 20% 내외 가산

2) 산출 근거 (CPU / Memory / Disk)

2.1 CPU 산정 근거

1. 동시접속(CCU) → vCPU 초기값

   • 경량중간 트랜잭션 기준으로 **vCPU 1개당 3050 CCU**를 시작점으로 잡고, 실측(APM/부하테스트) 기반으로 조정.

   • Mendix(자바) 컨테이너 1세트로 100 CCU 처리 초기값을 4~6 vCPU로 두되, 운영은 장애 시 단일 노드가 전량 처리해야 하므로 노드당 8 vCPU로 여유 배치.

2. 컨테이너 제한

   • 컨테이너별 **CPU 제한(--cpus, --cpuset-cpus)**을 명시해 노이즈 네이버 방지 및 예측성 확보.

   • 검증/운영에서 요청(Request)/제한(Limit) 개념(쿠버네티스 도입 시)을 적용하면 스케줄링 안정성↑.

요지: “100 CCU 단일 노드 수용(N+1)”을 목표로 노드당 8 vCPU를 초기 배치값으로 잡고, 부하테스트 결과에 따라 6~10 vCPU 범위에서 미세조정.

2.2 Memory 산정 근거

1. JVM 특성 반영

   • 총 RAM은 Heap + Non-heap(메타스페이스·스레드스택 등) + 네이티브/OS 캐시를 모두 고려해야 함.

   • 실무 규칙: 총 RAM ≈ Heap × 1.5~2.0 (Heap만 보면 부족해지는 경우 多).

2. 초기 Heap 가정 & 시스템 RAM

   • 개발: Heap 4~6GB → 16GB RAM(오버헤드 포함)

   • 검증: Heap 8~12GB → 32GB RAM

   • 운영: Heap 8~12GB(서비스 특성 따라 ↑↓) → 노드당 32GB RAM

   • JVM은 -Xms/-Xmx로 최소/최대 Heap을 명시하고, GC/Stop-the-world 시간·Old Gen 점유율·OOM 이벤트를 기준으로 조정.

3. 오버헤드 반영

   • OS 10~15%, Docker **5~10%**를 RAM 여유분으로 항상 포함(합계 약 20%) → 메모리 압박·스왑 회피.

2.3 Disk 산정 근거

1. 기본스토리지(OS/Docker/로그)

   • OS 설치·패키지 업데이트·커널 덤프·스냅샷 여유 포함 40~60GB

   • Docker 이미지/레이어/빌드캐시 30~60GB(멀티스테이지·정기 Prune 전제)

   • 시스템/컨테이너 로그 40~80GB(보존정책에 따라 가감)

2. 추가스토리지(앱 로그/미디어) — 산식 예시

   • 앱 로그(GB) = (평균 로그/일) × (보존일수) × 1.3 (피크·압축·인덱스 여지)

   • 미디어(GB) = (일평균 증가량) × (보존기간) × 1.2 (메타·썸네일·버전)

   • 업로드 파일/미디어는 컨테이너 외부 볼륨(PV)로 분리 마운트 권장(재배포/장애에도 데이터 보존).

3. 운영 권장 총량

   • 노드당 400GB(기본 200 + 추가 200)를 시작점으로 하고, 로그 보존·미디어 누적 정책에 따라 상향.

3) 환경별 VM 스펙(표)

표의 수치는 초기 배치값(Starting Size) 입니다. 배포 후 2~4주 간 APM/메트릭(docker stats) 관찰로 상·하향 리사이징 권장.

• 오버헤드 포함: 상기 스펙에는 OS 1015% + Docker 510% ≈ 20% 여유가 내재.

• 튜닝 포인트: CCU/초당 트랜잭션·DB대기·GC·스레드풀·I/O 차트로 병목 확인 → 보수적으로 시작해 점진 조정.

4) 적용 예시(숫자 대입)

• (운영 노드 기준) 앱 로그: 2GB/일 × 30일 × 1.3 ≈ 78GB → 100GB 할당

• (운영 노드 기준) 미디어: 1GB/일 × 180일 × 1.2 ≈ 216GB → 250GB PV 분리

• 합계 예: 기본 200GB + 추가(로그100 + 미디어250) = 550GB 필요 → 초기 400GB → 정책에 따라 600GB 수준으로 확대 검토

5) 운용 권장 수칙(요약)

• 리소스 제한: 컨테이너별 CPU/메모리 제한을 명시(--cpus, --memory, --memory-reservation).

• 모니터링: docker stats, 애플리케이션 APM, 노드/스토리지 I/O, GC/힙 그래프 상시 관측.

• 로그 정책: logrotate(size/rotate/keep), 컨테이너 로그 드라이버 옵션, 장기 보관은 외부 스토리지/ELK 전환.

• 이미지/레이어 관리: docker system df, docker image prune, docker system prune 주기 운영(볼륨 삭제 전 백업 필수).

• 데이터 볼륨: 업로드/미디어는 컨테이너 외부(PV) 로 분리, 스냅샷·백업 정책 수립.

6) 참고 URL(근거 자료)

• Docker — 컨테이너 리소스 제한: https://docs.docker.com/engine/containers/resource_constraints/

• Docker — docker stats(CPU/메모리/블록 I/O 모니터링): https://docs.docker.com/reference/cli/docker/container/stats/

• Docker — 디스크 사용 확인/정리(system df/prune):

  • https://docs.docker.com/reference/cli/docker/system/df/

  • https://docs.docker.com/engine/manage-resources/pruning/

  • https://docs.docker.com/reference/cli/docker/system/prune/

• Mendix — Docker 배포 가이드: https://docs.mendix.com/developerportal/deploy/docker-deploy/

• Mendix — Java 메모리 사용(Heap/Non-heap 개념): https://docs.mendix.com/refguide/java-memory-usage/

• (쿠버네티스 선택 시) 컨테이너 리소스 요청/제한: https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/

• Tomcat — JVM 힙 설정·튜닝: https://tomcat.apache.org/tomcat-9.0-doc/config/

• RHEL 8 — 시스템 요구사항(디스크/메모리 기준): https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/8/html/automatically_installing_rhel/system-requirements-and-supported-architectures_rhel-installer

한눈에 요약

• Dev: 4 vCPU / 16 GB / 200 GB

• QA: 8 vCPU / 32 GB / 300~400 GB

• Prod(HA, N+1): 노드당 8 vCPU / 32 GB / 400 GB(로그·미디어 정책에 따라 400~600 GB 조정)

• 오버헤드 20% 반영, 배포 후 2~4주 실측 기반 리사이징

필요하시면 이 내용을 PDF나 PPT로 바로 만들어 드릴게요. 어떤 형식이 좋을까요?

좋습니다 👍 요청하신 내용을 기반으로 개발 / 검증 / 운영 환경별 VM 서버 스펙 산정 근거를 문서 형태와 표 형태로 정리했습니다. CPU, Memory, Disk 각각의 산출 근거를 상세하게 기술하고, 관련 참고 URL도 포함했습니다.

VM 서버 스펙 산정 근거

1. 산정 기준

• 개발환경: 사용자 20명, 동시접속자 10명 (50%)

• 검증환경: 운영환경 부하의 60~70%를 단일 노드에서 검증

• 운영환경: 사용자 200명, 동시접속자 100명 (50%)

  • HA 2대 구성

  • N+1 원칙: 1노드 장애 시 단일 노드가 전체 부하(100 CCU)를 처리 목표

• 구성요소: Mendix App (Docker 컨테이너 기반)

• 스토리지 산정

  • 기본스토리지: OS, Docker 엔진/이미지, 시스템 로그

  • 추가스토리지: 애플리케이션 로그, 미디어 파일

• 오버헤드

  • Docker + Docker Compose: VM 자원의 5~10%

  • VM OS: VM 자원의 10~15%

  • 합산 약 20% 여유 반영

2. 산출 근거

2.1 CPU

• 산정 원칙

  • 경량 트랜잭션 기준 vCPU 1개는 30~50 동시접속자 처리 가능

  • Mendix App(자바 기반) 특성을 고려하여 100 CCU 처리에 약 4~6 vCPU 필요

  • 운영환경은 N+1을 위해 노드당 8 vCPU를 배치하여 장애 시 단일 노드로 전체 부하 수용 가능

• 참조 URL

  • Mendix Cloud Resource Guidelines

  • Docker Resource Constraints

2.2 Memory

• 산정 원칙

  • JVM 기반 앱은 Heap + Non-Heap + OS 캐시를 고려해야 함

  • 메모리는 Heap의 1.5~2배가 필요, 여기에 OS 및 Docker 오버헤드 20% 반영

  • 운영환경은 Heap 8~12GB 가정, 시스템 RAM 32GB 권장

• 참조 URL

  • Tomcat JVM Memory Tuning

  • RHEL 8 System Requirements

2.3 Disk

• 산정 원칙

  • 기본스토리지: OS 4060GB, Docker 이미지/레이어 3060GB, 시스템 로그 40~80GB

  • 추가스토리지:

    • 앱 로그 = (일평균 로그량 × 보존일수) × 1.3

    • 미디어 파일 = (일평균 증가량 × 보존기간) × 1.2

  • 운영환경은 노드당 400GB를 시작점으로 배치, 로그·미디어 보존 정책에 따라 확장

• 참조 URL

  • Docker Stats – Monitoring

  • USENIX ATC 2020 – Container Overhead Study

3. 환경별 VM 서버 스펙 (표)

4. 요약

• CPU: 운영환경은 장애 시 단일 노드 100 CCU 수용 가능하도록 노드당 8 vCPU

• Memory: JVM Heap + 오버헤드 고려, 노드당 32GB 권장

• Disk: 개발 200GB, 검증 300~400GB, 운영 노드당 400GB 이상

• 오버헤드: VM OS(1015%) + Docker(510%) ≈ 20% 여유 포함

👉 이 자료를 PDF 보고서나 PPT 발표자료로 변환해 드릴 수도 있습니다. 원하시는 출력 형식은 PDF일까요, PPT일까요?